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Status of This Memo 
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not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Copyright Notice 
Copyright (C) The IETF Trust (2007). 
Abstract 


There is a long-standing tradition in the Internet community, 
predating the Internet Engineering Task Force (IETF) by many years, 
of use of the RFC Series to publish materials that are not rooted in 
the IETF standards process and its review and approval mechanisms. 
These documents, known as "Independent Submissions", serve a number 
of important functions for the Internet community, both inside and 


outside of the community of active IETF participants. This document 
discusses the Independent Submission model and some reasons why it is 
important. It then describes editorial and processing norms that can 


be used for Independent Submissions as the community goes forward 
into new relationships between the IETF community and its primary 
technical publisher. 
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1. 


Introduction 


There is a long-standing tradition in the Internet community, 
predating the IETF by many years, of use of the RFC Series to publish 
materials that are not rooted in the IETF standards process and its 
review and approval mechanisms. These documents, known as 
"Independent Submissions", serve a number of important functions for 
the Internet community, both inside and outside of the community of 
active IETF participants. This document discusses the Independent 
Submission model and some reasons why it is important. It then 
describes editorial and processing norms that can be used for 
Independent Submissions as the community goes forward into new 
relationships between the IETF community and its primary technical 
publisher. 


To understand the perspective of this document, it is important to 
remember that the RFC Editor function predates the creation of the 
IETF. As of the time of this writing, the RFC Series goes back 38 
years [RFC2555], while the IETF is celebrating its 21st anniversary. 
All of the documents that were published before the IETF was created, 
and for some years thereafter, would be considered Independent 
Submissions today. As the IETF evolved, the Internet Architecture 
Board (IAB) and then the IETF itself chose to publish IETF documents 
as RFCs while fully understanding that the RFC Editor function was an 
independent publication mechanism. Other decisions were possible: 
e.g., the IETF could have decided to create its own publication 
series. It was felt that there was considerable value in continuing 
to publish the IETF work in the same series as the one used to 
publish the basic protocols for the Internet. 


1. Terminology Note 


This document describes what have historically been referred to as 
"Independent Submissions". That term is distinguished from those 
IETF and IAB community documents that originate from formal groups -- 
the IAB, IRTF, and IETF Working Groups -- and from submissions 
submitted to the Internet Engineering Steering Group (IESG) for 
Standards-Track, Informational, or Experimental processing. 

Documents produced by individuals, rather than IETF WGs or others 
IETF-affiliated groups, but submitted for publication via the IESG 
under Area Director sponsorship, are known as "individual 
submissions". 


For convenience and obvious historical reasons, the editor and 
publisher of documents that are not processed through the IETF is 
known below as the "RFC Editor". The RFC Editor will typically be an 
organization of one or more senior people and associated editorial 
staff, and the term is used collectively below. That term is not 
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intended to predict the future, either in terms of who does the job 
or what they, or the document series, are called. 


1.2. Context and Philosophical Assumptions 


This document complements the discussion and guidelines in [RFC4714], 
which focuses on Standards-Track documents. It takes a somewhat 
stronger view than the discussions that led to that document, 
starting from the belief that Independent Submissions are most 
valuable if they are, in fact, independent of the IETF process. From 
the perspective of the IETF, Independent Submissions are especially 
important as checks on the IETF processes even though such checks are 
not the only, or even a common, reason for them. That role is 
compromised if IETF-related entities are able to block or deprecate 
such documents to a degree beyond that needed to avoid difficulties 
with the standards process. 


2. The Role of Independent Submissions 


When the RFC Series was fairly new, RFCs were used to publish general 
papers on networking as well as the types of documents we would 
describe as standards today. Those roles also developed as part of 
the early design and development of the ARPANET, long before anyone 
dreamt of the IETF and when the distinction between, e.g., Standards 
and Informational documents was less precisely drawn. In more recent 
years, Independent Submissions have become important for multiple 
reasons, some of them relatively new. They include: 


o Discussion of Internet-related technologies that are not part of 
the IETF agenda. 


o Introduction of important new ideas as a bridge publication venue 
between academia and IETF engineering. 


o Informational discussions of technologies, options, or experience 
with protocols. 


o Informational publication of vendor-specific protocols. 


o Critiques and discussions of alternatives to IETF Standards-—Track 


protocols. The potential for such critiques provides an important 
check on the IETF’s standards processes and should be seen in that 
light. 


o Documents considered by IETF Working Groups but not standardized. 
While many documents of this type are still published in the IETF 
document stream (see [RFC4844], Section 5.1.1) as Informational or 
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Experimental RFCs, the Independent Submission path has 
traditionally been open to them as well. However, because of 
their intimate connection to the IETF Standards Process and WG 
activities and the consequent sensitivity to exact statements of 
relationships and to timing, there is reason to believe that such 
documents should normally be published via the IETF document 
stream. In any event, these documents are published for the 
historical record. 


o Satirical materials. 


o Meeting notes and reports (RFC 21 [RFC0021] is the earliest; RFC 
1109 [RFC1109] is probably the most important). 


o Editorials (the best example is IEN 137 [IEN137], not an RFC). 
o Eulogies (RFC 2441 [RFC2441]). 
o Technical contributions (e.g., RFC 1810 [RFC1810]). 


o Historically, RFC Editor and, at least prior to the handoff 
between the Informational Sciences Institute (ISI) and the 
Internet Corporation for Assigned Names and Numbers (ICANN) and 
the June 2000 MOU [RFC2860], Internet Assigned Numbers Authority 
(IANA) Policy Statements (e.g., RFC 2223 [RFC2223] and RFC 1591 
[RFC1591]). 


It should be clear from the list above that, to be effective, the 
review and approval process for Independent Submissions should be 
largely independent of the IETF. As an important principle that has 
been applied historically, the RFC Editor seeks advice from the IESG 
about possible relationships and conflicts with IETF work. Any 
submission that constitutes an alternative to, or is in conflict 
with, an IETF Standard or proposal for Standards-Track adoption must 
clearly indicate that relationship. The IESG may identify such 
conflicts as part of its review. 


The specific procedures to be followed in review are described in 
Section 4 and Section 5. 


3. Document Submission 


Independent Submissions are submitted directly to the RFC Editor. 
They must first be posted as Internet-Drafts (I-Ds), so the 
submission is typically simply a note requesting that the RFC Editor 
consider a particular Internet-Draft for publication. The process is 
described in [RFC2223]. Further information can be found in the 
working draft of an update of that document [RFC2223BIS]. 
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Any document that meets the requirements of this specification, of 
[RFC2223] and its successors, and of any intellectual property or 
other conditions that may be established from time to time, may be 
submitted to the RFC Editor for consideration as an Independent 
Submission. However, the RFC Editor prefers that documents created 
through IETF processes (e€.g., working group output) be considered by 
the IESG and submitted using this path only if a working group or the 
IESG declines to publish it. In the latter cases, the review process 
will be more efficient if the authors provide a history of 
consideration and reviews of the document at the time of submission. 


4. The Review Process 


In general, the steps in the review process are identified in the 
subsections below. Any of them may be iterated and, at the 
discretion of the RFC Editor, steps after the first may be taken out 
of order. In addition, the IESG review, as discussed in Section 5, 
must take place before a final decision is made on whether to publish 
the document. 


4.1. Posting of Draft 


The author(s) or editor(s) of a document post it as an Internet- 
Draft. 


4.2. Request for Publication 


After the normal opportunity for community review and feedback 
provided by the submission of the I-D and the I-D repository 
announcement thereof, the author or editor sends a request for 
consideration for publication to the RFC Editor at 
rfc-editor@rfc-editor.org. That request should note any community 
discussion or reviews of the document that have occurred before 
submission, as well as the desired document category (Informational 
or Experimental, as discussed in RFC 2026 [RFC2026], Section 4.2). 


If the document requires any IANA allocations, authors should take 
care to check the assignment policy for the relevant namespace, since 


some assignment policies (e.g., "IETF Consensus") cannot be used by 
Independent Submissions. See RFC 2434 [RFC2434] for more 
information. 


AN 3. Initial RFC Editor Review 


RFC Editor staff performs an initial check on the document to 
determine whether there are obvious issues or problems and to decide 
on the sequencing of other steps. 
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At any time during the process, the RFC Editor may make general 
and/or specific suggestions to the author on how to improve the 
editorial quality of the document and note any specific violations of 
the rules. The author will be expected to make the suggested 
updates, submit a new version, and inform the RFC Editor. This may 
be repeated as often as necessary to obtain an acceptable editorial 
quality. 


4.4. Review and Evaluation 
The RFC Editor arranges for one or more reviews of the document. 
This may include Editorial Board (see Section 6) reviews or reviews 
by others. Unsolicited reviews from parties independent of the 


author are welcome at any time. 


At minimum, the author of every document shall receive a written 


summary of the review(s). Reviewer anonymity is discussed in 
Section 7. The RFC Editor may also share reviews with the Editorial 
Board. 


An author rebuttal to some aspect of a review, followed by a healthy 
technical dialog among the author and the reviewer(s), is fully 
appropriate. Consensus followed by document revision is the desired 
outcome. 


The RFC Editor is expected to consider all competent reviews 
carefully, and in the absence of some unusual circumstance, a 
preponderance of favorable reviews should lead to publication. 


4.5. Additional Reviews 


If the author is dissatisfied with one or more review(s), the author 
may request that the RFC Editor solicit additional reviews. In 
exceptional circumstances, the author may request that the IAB review 
the document. Such requests to the IAB, and any reviews the IAB 
chooses to perform, will occur according to procedures of the IAB’s 
choosing. The IAB is not required to initiate a review or comply 
with a request for one: a request to the IAB for a review is not an 
appeal process. 


4.6. Document Rejection 


If any stage of the review process just described leads to the 
conclusion that the document is not publishable, the RFC Editor may 
reject the document. Such rejection would normally be based on the 
conclusion that the submission does not meet the technical or 
editorial standards of the RFC Series or is not relevant to the areas 
that the series covers. 
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If a document is rejected by the RFC Editor, the author may request 
an additional review from the IAB, as described below, but the IAB is 
not obligated to perform that review, nor is the RFC Editor obligated 
to publish it, even with a favorable IAB review. 


4.7. Final Decision and Notification 


In all cases, the ultimate decision to publish or not publish, and 
with what text, rests with the RFC Editor. 


The RFC Editor will communicate the final decision to the author and 
the Editorial Board. For a rejection, there will be a summary of the 
reason(s) for the action. 


Information about any IESG-requested publication delay or request to 
not publish a document will be posted to the RFC Editor Web site to 
supplement document status information. 


4.8. Final Editing and Publication 


Once a document is approved for publication, it is handled ina 
fashion similar to other RFCs, with principles about priorities 
worked out with the IAB as appropriate. 


5. Formal IESG Review 


At an appropriate time in the review process, normally after the RFC 
Editor has made a tentative decision to publish, the document is 
forwarded to the IESG for evaluation with a relatively short timeout. 
If the nature of the document persuades the RFC Editor or the IESG 
that the interests of the community or efficiency in the publication 
process would be better served by a different schedule, then that 
schedule should be followed. For example, if it appears to the RFC 
Editor that it is likely that the IESG will wish to take the document 
over and assign it to a working group, it may be better to ask for 
the IESG review prior to incurring the delays associated with other 
reviews or significant editorial work. 


The IESG evaluation is not a technical one. Instead, it covers the 
issues listed in RFC 3932 [RFC3932] or its successors, presumably 
from the perspective outlined above in Section 1.2. That is, the 
evaluation should focus exclusively on conflicts or confusion with 
IETF process and attempts to subvert ("end run") working group 
activities. 


At the time the document is forwarded to the IESG, the RFC Editor 


posts an indication on its Web site that the document is under IESG 
review and that comments on conflicts can be sent to the IESG with 
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copies to the RFC Editor. Additional mechanisms may be developed 
from time to time to inform a community that a document is entering 
formal prepublication review. Comments not directly related to IETF 
procedures or conflicts may be sent directly to the author(s) and RFC 
Editor. 


In addition to the IESG review for conflict with IETF work, 
individuals in the IESG or in the broader IETF community are free to 
review a draft and, if they have comments of any kind --including the 
extreme case of believing that the proposal is damaging to the 
Internet as a whole-- these comments should be directed to the 
author(s) and the RFC Editor. 


If the IESG, after completing its review, identifies issues, it may 
recommend explanatory or qualifying text for the RFC Editor to 
include in the document if it is published. 


If the IESG concludes that publication of the document should be 
delayed for a reasonable period of time because its untimely 
publication could cause confusion or other harm with proposals under 
consideration for standardization, the RFC Editor will grant that 
request. The current agreement between the RFC Editor and the IESG 
on requested delays is expected to continue. That agreement permits 
the IESG to ask for a delay of up to six months and, if necessary, to 
renew that request twice, for a total possible delay of 18 months. 


If the IESG concludes that the document should not be published as an 
RFC, it will request that the RFC Editor not publish and provide 
appropriate justification for that request. The RFC Editor will 
consider the request to not publish the document. 


The RFC Editor or the author may request that the IAB review the 
IESG’s request to delay or not publish the document and request that 
the IAB provide an additional opinion. Such a request will be made 
public via the RFC Editor Web site. As with the IESG review itself, 
the IAB’s opinion, if any, will be advisory. And, as with author 
requests for an IAB technical review (see Section 4.5), the IAB is 
not obligated to perform this type of review and may decline the 
request. 


6. The Editorial Review Board 


The RFC Editor appoints and maintains the Editorial Review Board, 
which, much like the editorial boards of professional journals and 
publishers, provides the RFC Editor with both advice and reviews of 
particular proposed publications and general and strategic policy 
advice. The membership list of the Editorial Review Board is public 
and can be found at http://www.rfc-editor.org/edboard.html. 
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Editorial Board members serve at the pleasure of the RFC Editor. 
From time to time, the RFC Editor will solicit suggestions for new 
appointees from the IAB and other sources and will seek IAB comments 
on those to be appointed. The RFC Editor will also solicit IAB 
comments on the effectiveness of the review process and the quality 
of documents being published and criteria applied. However, to 
ensure the independence of the Independent Submission process, the 
final decision to appoint (or not appoint) Editorial Board members 
rests with the RFC Editor. 


7. Status and Availability of Reviews 


The RFC Editor will conduct the reviews discussed above with the 
intent of balancing fairness to authors, transparency of the review 
process to the general community, protection of reviewers from 
possible retaliation or undue pressure, and the interest of the 
community in having any significant dissents from published documents 
available to the community with the same degree of scrutiny that the 
original documents received. To this end, reviews and information 
about reviewers will be made public under the following 
circumstances. In special cases in which other considerations apply, 
the RFC Editor may adopt special provisions after reviewing the 
circumstances and proposed action with the IAB. 


Any reviewer participating in the process outlined in this document 
does so on the condition of giving consent to handling of the reviews 
as outlined in this section. In special cases, individual 
arrangements may be worked out in advance with the RFC Editor. 


As described in Section 4.4, all reviews will be shared with the 
document authors (with possible editing to remove any extreme 
language). The names of the reviewers will normally accompany these 
reviews, but reviewers will be granted anonymity upon request to the 
RFC Editor. The RFC Editor will in any case forward any author 
rebuttal messages to the reviewer. 


Nothing in this section or the subsections below precludes private 
communications between reviewers, the Editorial Board, and the RFC 
Editor; such communications will remain confidential. 


7.1. Posted Reviews 


Once a final accept or reject decision has been made on a document, 
the RFC Editor may choose to post the full set of reviews (and author 
rebuttals, if any) associated with a document, if doing so would be 
in the best interest of the community. The author may request 
earlier posting of reviews and rebuttals, to inspire additional 
unsolicited reviews, for example. The names of the reviewers will 


Klensin & Thaler Informational [Page 10] 


RFC 4846 Independent Submissions July 2007 


accompany their reviews, except for a reviewer who requested 
anonymity. 


The author will be notified in advance of the intent to post the 
final reviews. The author may then request that the document be 
withdrawn and the reviews kept private. However, such an author 
request must be timely, generally within 14 days of the notification 
of intent to post. 


7.2. Rejected Documents 


If the RFC Editor rejects a document, the author has the following 
options for recourse. 


o Request one or more additional reviews (Section 4.5) followed by a 
reconsideration. 


o Request an IAB review (Section 4.5, Section 4.6) followed by a 
reconsideration. 


o Request that the reviews be published on the RFC Editor Web site. 
7.3. Documents Approved for Publication 


In considering whether to make review materials public for documents 
accepted for publication, the RFC Editor is expected to note that the 
best way to comment on or dissent from an RFC is generally another 
RFC; that reviews critical of a document are not themselves reviewed; 
that the review and refutation process is necessarily fragmentary; 
and that a reviewer who feels strongly about a subject about which a 
review has already been written often would not need to do 
significant additional work to produce an RFC-format document from 
that review. 


8. Intellectual Property Rights 


The following material was extracted from the relevant sections of 
BCP 78 [RFC3978] [RFC4748] in order to get all Independent Submission 
information for technical publications produced under the auspices of 
the IETF, the IETF Administrative Support Activity (IASA) or the IETF 
Trust, or the Internet Society (ISOC) into a single place and to 
initialize the process of separating discussions of Independent 
Submissions from those about Standards-Track or other IETF documents. 
Note that the text that follows uses the term "RFC Editor 
Contribution" to describe the same type of document referred to as an 
"Independent Submission" elsewhere in this document. The RFC Editor 
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may change these provisions from time to time after obtaining the 
advice and consent of the IETF Trust in the RFC Editor’s capacity as 
the formal publisher of RFCs. 


By submission of an RFC Editor Contribution, each person actually 
submitting the RFC Editor Contribution, and each named co- 
Contributor, is deemed to agree to the following terms and 
conditions, and to grant the following rights, on his or her own 
behalf and on behalf of the organization the Contributor represents 
or is sponsored by (if any) when submitting the RFC Editor 
Contribution. 


a. For Internet-Drafts that are expected to be submitted as RFC 
Editor Contributions: To the extent that an RFC Editor 
Contribution or any portion thereof is protected by copyright and 
other rights of authorship, the Contributor, and each named co- 
Contributor, and the organization he or she represents or is 
sponsored by (if any) grant an irrevocable, non-exclusive, 
royalty-free, world-wide right and license to the IETF Trust and 
the IETF under all intellectual property rights in the RFC Editor 
Contribution for at least the life of the Internet-Draft, to 
copy, publish, display, and distribute the RFC Editor 
Contribution as an Internet-Draft. 


b. For an RFC Editor Contribution submitted for publication as an 
RFC, and to the extent described above, the Contributor, each 
named co-Contributor, and the organizations represented above 
grant the same license to those organizations and to the 
community as a whole to copy, publish, display, and distribute 
the RFC Editor Contribution irrevocably and in perpetuity and, 
also irrevocably and in perpetuity, grant the rights listed below 
to those organizations and entities and to the community: 


A. to prepare or allow the preparation of translations of the 
RFC into languages other than English, 


B. unless explicitly disallowed in the notices contained in an 
RFC Editor Contribution, to prepare derivative works (other 
than translations) that are based on or incorporate all or 
part of the RFC Editor Contribution, or comment upon it. The 
license to such derivative works shall not grant the IETF 
Trust, the IETF, or other party preparing a derivative work 
any more rights than the license to the original RFC Editor 
Contribution, and 


C. to reproduce any trademarks, service marks, or trade names 


that are included in the RFC Editor Contribution solely in 
connection with the reproduction, distribution, or 
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9. 


10. 


11. 


Tiks 


publication of the RFC Editor Contribution and derivative 
works thereof as permitted by this paragraph. Any entity 
reproducing RFC Editor Contributions will, as a condition of 
permission of such reproduction, preserve trademark and 
service mark identifiers used by the Contributor of the RFC 
Editor Contribution, including (TM) and (R) where 
appropriate. 


D. The Contributor grants the IETF Trust and the IETF, 
permission to reference the name(s) and address(es) of the 
Contributor(s) and of the organization(s) s/he represents or 
is sponsored by (if any). 


Security Considerations 


This document specifies an RFC Editor (and, indirectly, IETF) 
administrative and publication procedure. It has no specific 
security implications. 
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This document is subject to the rights, licenses and restrictions 
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retain all their rights. 
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Intellectual Property 
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Intellectual Property Rights or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has 
made any independent effort to identify any such rights. Information 
on the procedures with respect to rights in RFC documents can be 
found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
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